Web applications are often deployed using multiple interconnected computers configured as cluster. A cluster configuration can enable various benefits for the system, such as increased scalability and availability.
A cluster can provide scalability by enabling the system to spread load across multiple nodes of the cluster. For example, a cluster may be used to deploy a web application by executing a separate application server instance on each node. Because each application server instance is capable of handling web requests, the cluster enjoys the combined computational resources of all the nodes in the cluster. Often, the cluster includes a load-balancer that receives network requests, applies some load-balancing algorithm to decide which server instance should service the request, and forwards the request to the determined node. By applying such load-balancing algorithms, a load-balancer may optimize cluster utilization to avoid hotspots.
Another property that cluster configurations may enhance is availability. For a web application executing in a non-clustered environment, a server failure makes the web application unavailable until the server is repaired. In contrast, cluster environments enable failover techniques, whereby, when one node fails (primary server), another node (recovery server) may service the load of the failed node. Failover techniques may be implemented such that the server failure is transparent to clients.
One difficulty of implementing transparent failover for web applications is that servers often maintains respective session data for each client. Session data is data that the server must maintain for the duration of a client's session (i.e., session scope), rather than for the duration of only one request (i.e., request scope). For example, an e-commerce web application might maintain session data indicating the items that a user has stored in his shopping cart. The system must maintain such data across multiple requests so that the user's shopping cart maintains the items, even after the user navigates to a new page. To implement transparent failover, a recovery server must have access to a client's session data.
Different methods exist for implementing transparent failover for web applications that store session data. In some systems, servers write session data to a persistent back-end store, such as a shared database or file system. If a server crashes, then the recovery server may access the session data in the shared persistent storage. Unfortunately, writing session data to shared persistent store often imposes a significant performance penalty. Furthermore, implementing the persistent store implicates additional cost and complexity.
Another technique for implementing transparent failover is in-memory replication of session data. In such systems, a server always backs up its session data onto another server (backup server) in the cluster. If the node fails, the load balancer routes the next client request to another server, which then uses some protocol to locate the backup server. The server may either retrieve the session data from the backup server and serve the client or forward the request to the backup server. Whichever server handles the request also chooses a new backup server to which it replicates the session data.